【进阶•DNS分流篇】彻底弄懂DNS泄漏,让DNS不再玄学,详解DNS在透明代理中的行为,redir

您所在的位置:网站首页 openclash 软路由 响应 时间 【进阶•DNS分流篇】彻底弄懂DNS泄漏,让DNS不再玄学,详解DNS在透明代理中的行为,redir

【进阶•DNS分流篇】彻底弄懂DNS泄漏,让DNS不再玄学,详解DNS在透明代理中的行为,redir

2023-12-23 15:38| 来源: 网络整理| 查看: 265

查询dns泄露:https://ipleak.net

视频教程

视频地址:https://youtu.be/aKlH6KRt9Jc

上期我们讲过了DNS的执行流程以及常见的客户端解决DNS泄露的方法由于时间关系只给大家演示了设置步骤 并没有说明为什么要那样设置导致很多使用其他客户端的朋友不知道该如何设置我也不可能所有的客户端都演示一遍 主要是有很多我也没用过 其实这么多不同的客户端逻辑都是一样的安卓的clash for andorid电脑的clash for windows 软路由的openclash 其实都是调用clash的内核只是操作界面不太一样 所以本期就来接着上期的话题展开讲讲 让很多人难以理解的DNS分流看完之后 如果你理解了 就不会因为软件的界面不同而不知道该如何设置了 并且也能做出符合自己需求的分流配置先来回顾上节的内容 创建一个最常见的家庭网络环境 你在运营商拉了一条宽带 它会给你分配一个光猫一般来讲你会单独在购买一个路由器连接光猫路由器通过PPPOE拨号获取运营商分配的公网IP同时路由器作为局域网的网关会有自己的内网IP地址假设为 192.168.0.1家里的所有网络设备都会连接到这台路由器路由器通过 DHCP 为每一台网络设备分配一个内网 IP 以及默认网关 DNS 等信息一般情况下 默认网关和 DNS 服务器都是路由器这是最常见的家庭网络拓扑先以第一节介绍过的Clash系统代理为例当我们在电脑上运行Clash for Windows时其实 它是调用了clash的内核 并且加载了yaml配置文件 配置文件可能是机场提供的订阅地址 或者是你通过订阅转换获取的总之 配置文件的内容大概长这样 监听端口7890配置了两个节点以及两个节点组第一个节点组包含两个节点默认选中了香港节点第二个节点组包含两个节点 默认选择了美国节点下面是一些分流规则此时浏览器访问www.google.com由于设置了系统代理 访问谷歌的请求会被浏览器转发到系统代理监听的端口7890clash从7890端口收到数据后 会解析数据报的内容知道浏览器想要访问谷歌clash有全局、规则、直连、脚本 四种分流模式 大家一般用的都是规则模式于是进入规则匹配从上到下一条条匹配规则 语法建议看官方文档我这里简要给大家说明一下第一条匹配域名规则如果访问的是google.com则交给节点组1默认选中的节点是香港节点所以会将请求交给香港节点但我们访问的是www.google.com而不是google.com所以不匹配进入下一条下一条规则是后缀匹配youtube.com很明显也不匹配再下一条规则是关键字匹配 youtube 很明显也不匹配 下一条又是域名匹配 如果是ad.com直接reject掉 相当于丢弃 主要用于广告屏蔽再下一条匹配源IP段如果源IP段是192.168.1.201那么就走direct,也就是直连主要用于局域网其他设备的分流由于这个请求是本机浏览器直接发送给clash的所以原IP为127.0.0.1因此这条规则也不匹配 下一条匹配目标IP段如果访问的目标是127.0.0.0/8这个网段就走direct直连但是我们用来匹配的是www.google.com这个域名很明显IP和域名是没办法进行对比的 所以需要先通过上集讲的DNS解析获取谷歌的IP地址但是这条匹配规则后面加上no-resolve 表示不进行DNS解析 相当于直接跳过了这条基于IP的匹配规则下一条是IPv6的匹配规则同样加了no-resolve 也直接跳过了 再下一条匹配GEOIPGEOIP是一个数据库里面包含了常见的IP归属地分类如果是国内的IP就走直连 由于后面没有加no-resolve 所以需要将谷歌的域名解析为IP进行匹配由于clash没有配置DNS模块 所以会交给电脑配置的本地DNS服务器进行解析clash会构建一条查询谷歌域名的DNS请求发送给电脑配置的本地DNS服务器也就是路由器由于DNS请求是明文的此时就产生了DNS泄露 后面的解析步骤就是上期讲过的内容了这里要注意的是 请求被墙的域名大概率你会收到一条被污染的DNS响应假设谷歌的真实IP是4.4.4.4但是你收到的谷歌IP却是5.5.5.5这就是DNS污染clash拿到这个被污染的DNS响应 以为谷歌的IP就是5.5.5.5于是会用这个IP和GEOIP的规则进行匹配发现这个IP的归属地不是国内所以这条规则也是不匹配的有的朋友可能有疑问 你怎么知道他不是国内的 我也不知道 猜的因为一般情况下不会污染成国内的IP 但也不能保证大家可以思考一下如果是国内的IP会导致什么情况接着匹配源端口和目标端口以及进程名称如果是curl这个进程发起的请求 则交给节点组2节点组2默认选中了美国的节点 很明显以上规则都无法匹配www.google.comclash还有一个兜底叫做MATCH所有没有匹配的规则全都交给MATCH处理 也就是节点组1所以这条访问谷歌的请求交给了节点组1的香港节点将会使用香港ss节点的配置信息对数据进行加密 这里要注意的是 刚才DNS获取到的IP只是用来进行IP规则的分流匹配你发给香港节点还是域名 所以节点收到数据后 会在他的网络环境中再次进行DNS解析 获取了正确的谷歌IP本地的DNS污染并不会影响但是存在DNS泄露解决这个问题有两个方法一种是上期给大家提供的解决方案 给所有基于IP分流的匹配规则都加上no-resolve这样就不会触发DNS请求但是会有一个问题 假如此时我想访问百度clash说到请求后会一条条进行匹配 当来到GEOIP这条规则时如果没有加no-resolve会发起DNS请求 获取百度的IP返回的肯定是一个国内的IP也就匹配上了这条规则将会走直连但是为了防止DNS泄露 我加上了no-resolve这样就不会发起DNS请求百度的域名也就无法和IP归属地进行匹配这条规则直接跳过了 最终将会交给MATCH走代理出去这肯定不是我们所希望看到的所以我给大家提供的配置文件中不仅所有IP规则都加上了no-resolve同时加上了国内域名走直连的分流规则 这样百度等国内网站通过域名匹配也可以走直连但是一些小众的国内网站并不在规则列表里所以会出现走代理的情况这其实就是v2rayN的绕过大陆模式这样的匹配效率最高 不会为了分流而发起DNS请求所有国外网站都会走代理缺点是一些小众的国内网站也会走代理 你可能需要单独为这些网站添加走直连的规则如果你平时主要访问国外网站 这种模式比较适合你 另一种方式类似v2rayN的黑名单模式就是在IP规则前先把所有的黑名单网站的匹配规则先加上比如google youtubefacebook twitter等等这样就可以优先匹配到域名规则直接交给节点处理不会再往下匹配也就不会触发IP规则的DNS请求了 需要注意的是 有些机场的clash订阅会把没将no-resolve的IP规则放在前面 导致优先发起了DNS请求 造成DNS泄露如果用这个配置访问上期演示过的DNS泄露网站 由于没有匹配到上面的任何规则会来到GEOIP这条没有加no-resolve的IP规则 于是使用本地DNS发起了DNS请求之前也讲过 这个网站会记录你的上游DNS服器的IP地址 很显然列表中将会显示国内的DNS提供商clash得到IP后 发现归属地不是国内 于是会继续向下匹配 最终还是走了代理节点收到域名后会再次进行DNS获取IP所以列表中的香港DNS是节点服务器使用的DNS提供商上期我开头说如果列表中有国内的DNS提供商说明 肯定泄露了那你觉得这种情况算DNS泄露吗虽然检测到了国内的DNS提供商但是如果你只在意googleyoutube等网站有没有泄露这样的配置确实是没有泄露吗真有这么简单的话 就不会难倒这么多人了如果使用系统代理这种侵入性较小的方式确实这样的分流配置就能解决DNS泄露真正让人难以理解的是在软路由手机端和TUN模式这种透明代理的情况下的DNS流程前面讲的这么多主要是让大家熟悉clash的执行流程 接下来才是本期的重点 先来改变一下当前的网络结构clash不再设置为系统代理而是开启了TUN模式或者不在电脑中运行 直接运行在路由器里路由器会将局网其他设备访问互联网的数据转交给clash 这样更容易理解一点 配置文件跟系统代理主要的区别是添加了DNS模块此时浏览器访问谷歌根据上期讲的内容 浏览器将首先发起DNS请求获取谷歌的IP数据包会来到路由器路由器会将DNS请求劫持到clash中clash收到浏览器的DNS请求他也不知道谷歌的IP是多少再看看自己的DNS配置是redir-host的模式这个模式必须给浏览器返回一个真实的IP所以 clash需要先获取谷歌的IP地址于是向这三个上游DNS服务器同时发起DNS请求谁第一个返回就用谁的结果假设114最先返回了谷歌的IP为5.5.5.5记住这个是被污染的结果clash有个映射表 用于保存查询的结果并将结果返回给浏览器浏览器拿到谷歌的IP 向这个IP发起访问谷歌的http请求 请求来到路由器的clashclash查看映射表中IP对应的域名 用域名进行规则匹配 匹配了第一条规则 于是将请求交给节点组1的香港节点处理这里要注意交给节点处理的还是谷歌的域名 由远程的节点服务器再次进行DNS解析获取正确的谷歌IP 所以本地即使是污染的IP也并没有关系但由于redir-host必须给浏览器返回一个真实的IP 所以clash必然要发起DNS请求去获取谷歌的IP这样就必然存在DNS泄露还有一个更大的问题假如浏览器接下来访问youtube还是先发起DNS请求获取youtube的IP 由于使用redir-host的模式clash会向三个上游DNS服务器同时发起查询youtube IP的DNS请求假设114最先返回youtube的IP为5.5.5.5 和刚才谷歌的IP一样 他们搭建在同一个服务器上或者说被污染到同一个地址浏览器拿到IP后发起访问youtube的http请求请求来到clash这时查看映射表就出了问题IP是一样的clash不知道要访问哪个域名大家可能会想 http请求中不是有youtube的域名吗直接看http的域名不就行了但是clash并没有类似v2ray的流量探测功能 所以无法探测http请求的域名为了解决这个问题clash的redir-host模式不再进行远程DNS也就是节点服务器收到的直接就是5.5.5.5这个IP地址这样就不需要查看映射表了但是又会造成另一个问题5.5.5.5是被污染的IP节点服务器拿到这个IP肯定无法正确的访问youtube 如果被污染的这个IP确实搭建了网站还会出现访问youtube却进入其他网站的奇特现象 由于证书和域名不匹配 浏览器会发出报警并且有时会污染到一个保留IP 会出现其他意料之外的情况 此时可以加上fallback解决DNS污染的问题里面主要放不会被污染的DNS服务器比如经过加密的dot或者doh 当发起DNS请求的时候会同时向上游的三个DNS服务器以及fallback中的DNS服务器发起DNS请求如果上游DNS服务器返回的IP不是国内的就使用fallback中DNS返回的IP 以确保国外IP没有被污染节点服务器可以拿到正确的IP进行访问 但是这样又会引起其他的问题原本我以为clash的doh域名会匹配规则走代理但经过测试发现是走直连我不知道是不是bug 按正常逻辑应该要走代理所以doh是通过本机IP直接发起的 获取到的IP地址是和本机地理位置相近的CDN服务器这个结果对节点服务器而言可能位置比较远无法获得cdn优化甚至可能导致速度变慢关于cdn的原理 我在节点搭建系列介绍过另外国内直联国外doh体验极差 间歇性被墙而且加密DNS需要先握手建立连接 延迟也比较高所以国外加密DNS提供商基本提供不了服务还有一些机场提供DNS解锁流媒体的服务 如果直接传IP给节点节点就无法发起DNS请求导致解锁无效关于DNS解锁原理 我在奈飞解锁那期也讲过 眼看redir-host的问题越修越多就在上个月官方直接把redir-host的模式砍了是的没错 直接就砍了果然解决提出问题的人才能彻底的解决问题其实这个问题clash meta通过加入流量探测功能解决了 后面有机会再说目前clash做透明代理 主要使用fakeip模式ios端的小火箭 QuantumultX surge都是用fakeip v2ray也有fakeip功能叫做fakeDNS或者虚拟DNS说的都是同一个东西当我们把DNS配置为fakeip之后此时浏览器访问谷歌浏览器 首先发起DNS请求 获取谷歌的IP请求会来到路由器路由器会将DNS请求劫持到clash中clash收到浏览器的DNS请求 他也不知道谷歌的IP是多少再看看自己的DNS配置是fakeipfakeip并不需要给浏览器返回一个真实的IPclash会心一笑 直接从配置的私有IP段中选择一个假的IP 生成DNS响应返回给浏览器 并且记录了IP和域名的映射关系 浏览器拿到这个假的IP之后 向这个IP发起访问谷歌的dns请求请求来到路由器的clash clash查看映射表中IP对应的域名 用域名进行规则匹配匹配到了第一条规则于是将请求交给节点组1的香港节点处理交给节点处理的还是谷歌的域名由远程的节点服务器进行DNS解析 获取谷歌的正确IP 可以看到本地 并不需要进行DNS解析也就不存在DNS泄露了 延迟也会降低 并且解决了多域名指向同一个IP的情况因为返回的都是假的IP clash可以控制每个IP只对应一个域名 如果此时再访问DNS泄露网站首先会返回一个假IP给浏览器浏览器在发起http请求clash拿到映射的域名进行匹配由于没有匹配到上面任何规则 会来到GEOIP这条没加no-resolve的IP规则此时clash也不知道这个域名的IP 于是同时向上游的三个DNS服务器和fallback中的DNS服务器发起DNS请求clash得到IP后 发现归属地不是国内于是会继续向下匹配最终匹配MATCH走了代理由于同时向多个DNS发起请求泄露测试列表中会返回好几家DNS提供商这种情况算不算泄露就仁者见仁了 如果你认为谷歌这种黑名单网站没漏就不算泄露的话 也并没有什么不妥fakeip这种侵入式的解决方案也并不完美 虽然能少一次DNS请求 降低延迟但毕竟是假的IP在某些情况下会出现不可预料的问题比如访问百度获取到了假的IP一段时间后 clash意外退出了而电脑中缓存了百度的假IP再次访问百度的时候就会访问假IP此时就会无法访问虽然clash将DNS响应中的缓存ttl值设置为一秒但上期也说了 应用程序并不一定会遵守ttl值的规定 为了防止频繁发起DNS请求可能会延长缓存时间 还有一些程序会开启DNS重绑保护 当DNS获取到一个私有IP则认为出现了非法DNS劫持而被丢弃典型的是windows系统使用fakeip会出现联网图标显示没网的情况解决方法是加入fake-ip-filter放在里面的域名不会返回假的IP会发起DNS请求 获取真实的IP地址相当于回退到redir-host的模式如果你对redir-host情有独钟 可以通过添加"+.*"通配符来回退所有域名这样fakeip模式就会完全变成redir-host模式 不过并不建议大家这么做 另外由于UDP在有些场景下必须使用真实的IP所以 目前clash处理udp流量的域名 即使是使用fakeip模式也一定会发起DNS请求比如基于UDP的QUIC协议 也就是浏览器用的HTTP3 启用了QUIC的浏览器访问youtube这种支持QUIC的网站就会发起DNS请求导致DNS泄露解决办法是禁用浏览器的QUIC功能至于其他fakeip客户端对UDP是不是同样的处理方式我不清楚反正clash目前是这样子的 虽然有这些小问题 但是瑕不掩瑜clash还是非常强大好用的如果你平时使用并没有感觉到这些问题的存在那么fakeip就是不错的选择fakeip可能不是最优的解决方案但是延迟最低这是毋庸置疑的毕竟在透明代理的情况下不发起DNS请求 只有fakeip能做到但是也不能否认fakeip存在的问题如果觉得fakeip不好用 可以使用v2ray系或者sing-box通过真实的DNS请求配合流量嗅探解决fakeip存在的问题 这又是另一个比较大的篇幅了 下期再说



【本文地址】


今日新闻


推荐新闻


CopyRight 2018-2019 办公设备维修网 版权所有 豫ICP备15022753号-3